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Real-Time/Predictive  Medical  Data  Fusion  Watchboard 
Phase  I  Option  Final  Report 


ScenPro,  Inc.  is  pleased  to  provide  this  Phase  I  Option  Final  Report  for  SBIR  Topic 
number  N99-025,  “Real-Time/Predictive  Medical  Data  Fusion  Watchboard,”  award 
contract  number  N00014-99-M-0135.  This  document  describes  the  Phase  I  research  and 
the  development  of  a  prototype  Real-time/Predictive  Medical  Data  Fusion  Watchboard 
(referred  to  as  NavMedWatch).  Specifically,  this  report  outlines  the  findings  of  research 
performed  during  the  Phase  I  Option  period  ending  May  23,  2000. 

NavMedWatch  was  designed  to  enhance  the  current  Navy  medical  care  system  and 
improve  medical  readiness.  The  watchboard  tool  described  in  this  report  would  provide 
streamlined  data  to  Navy  medical  care  providers,  support  personnel  and  remote  command 
staff  allowing  for  the  rapid  visualization  and  assessment  of  the  tactical  medical  situation. 

NavMedWatch  is  designed  to  gather  data  from  existing  sources  including  TMIP  (Theater 
Medical  Information  Program),  TMCS  (Theatre  Medical  Core  Services),  FMSS  (Field 
Medical  Surveillance  System),  pre-configured  databases,  and/or  Internet  Repositories,  as 
well  as  from  future  sources  such  as  personnel  status  monitors,  personnel  locators,  and 
Personal  Identification  Cards.  NavMedWatch  displays  are  designed  to  include  graphical, 
textual,  and  color  coding  of  relevant  data  for  quick  and  easy  interpretation  and  analysis. 

1.0  System  Architectere 

As  described  in  the  Phase  I  Final  Technical  Report  (dated  October  31,  1999),  the 
proposed  watchboard  architecture  is  broken  down  into  two  functional  areas  -  the  Medical 
Treatment  Facility  (MTF)  and  the  Joint  Task  Force  (JTF).  The  MTF  NavMedWatch  is 
designed  to  be  used  in  a  stand-alone  fashion,  while  the  JTF  NavMedWatch  would  be 
used  to  display  summary  status  information  at  the  theater  level.  In  addition,  the  JTF 
NavMedWatch  would  allow  users  to  access  information  associated  with  individual 
MTFs.  Figure  1  illustrates  an  example  communication  architecture  within  a  Theater  of 
Operation.  Each  MTF  has  one  or  more  NavMedWatch  tools  connected,  via  an  intranet, 
to  each  other  as  well  as  to  the  JTF  NavMedWatch. 


Figure  1.  Example  Communication  Architecture  for  a  Theater  of  Operation 
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A  more  detailed  view  of  the  connectivity  between  the  NavMedWatch  tools  is  illustrated 
in  Figure  2.  This  configuration  is  the  same  for  both  the  MTF  and  JTF  environments. 
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Figure  2.  JTF/MTF  NavMedWatch  Configuration 


The  data  used  to  populate  the  NavMedWatch  tool  can  be  provided  by  a  variety  of  data 
sources.  During  the  Phase  I  portion  of  the  contract,  the  TMCS  program  was  studied  as  a 
possible  data  source.  During  the  Phase  I  Option  period,  selected  sources  from  the 
Theater  Medical  Information  Program  (TMIP)  were  studied.  Both  provide  viable 
sources  of  example  input  data.  The  research  conducted  on  the  TMIP  database  structure  is 
discussed  in  more  detail  in  the  Section  2.0  Research  Performed. 


The  “JTF/MTF  HTML  pages”  box  shown  in  Figure  2  connected  to  the  Internet  figure 
represents  the  network  connection  of  multiple  NavMedWatch  tools  within  the  theater. 
The  “Local  Intranet”  connection  illustrates  how  the  multiple  NavMedWatch  tools  can  be 
configured  within  an  MTF  or  JTF  site.  One  NavMedWatch  tool  acts  as  the  primary 
watchboard  while  the  other  tools  are  connected  on  the  intranet  and  act  as  remote 
watchboard  sites.  The  primary  NavMedWatch  tool  would  require  that  Visio™  be 
installed  on  the  user’s  workstation.  This  tool  would  then  export  Visio  screens  as  html 
pages  to  a  pre-determined  universal  resource  locator  (url).  The  remote  users  can  then 
access  and  display  the  exported  NavMedWatch  screens  via  an  internet  browser  (such  as 
Internet  Explorer). 


ScenPro,  Inc. 
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1.1  NavMedWatch  Components 

The  NavMedWatch  tool  architecture  (illustrated  in  Figure  3)  is  composed  of  the 
following  7  components: 

•  User  Interface/Monitor, 

•  Data  Interface, 

•  System  Controller  (includes  the  display  functionality), 

•  Predictive  Casualty  Management  Simulation, 

•  Intelligent  Interviewing  Agent, 

•  Epidemiological  Predictions, 

•  Historical  Data  and  Playback. 
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Figure  3.  NavMedWatch  Components 

As  described  in  the  Phase  I  Final  Technical  Report,  the  System  Controller  provides  the 
“brains”  of  the  tool.  The  System  Controller  formats  and  displays  the  information  on  the 
User  Interface/Monitor.  It  compares  selected  information  (such  as  bed  availability) 
against  predetermined  thresholds  and  applies  the  following  color-coding  scheme: 


•  Red  represents  resource  values  that  are  equal  to  or  above  the  defined  threshold. 

The  System  Controller  is  also  responsible  for  the  automatic  screen  updates  and  the 
manual  “refresh”  functions.  The  Data  Interface  function  formats  messages,  database 
queries,  etc.  that  are  required  in  order  to  access  remote  data  sources.  The  Predictive 
Casualty  Management  Simulation  (PCMS)  takes  the  current  status  of  the  patient  load 
and,  using  medical  treatment  protocols  (such  as  Task-Time-Treater  files),  simulates  the 
flow  of  casualties  over  time.  The  PCMS  works  by  simulating  the  movement  of  each 
casualty  through  the  appropriate  treatment  protocol  while  tracking  the  associated  resource 
consumption.  The  output  of  the  PCMS  is  a  list  of  resources  required  to  treat  a  defined 
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casualty  stream.  This  list  of  resources  is  then  compared  to  the  list  of  available  resources 
for  the  selected  MTF.  When  resource  shortfalls  are  identified,  the  Intelligent 
Interviewing  Agent  uses  its  knowledge  of  medical  asset  availability  and  medical 
procedures  to  identify  and  display  additional  or  alternate  resources.  The  Epidemiological 
Predictions  include  links  to  the  charts  and  graphs  produced  by  the  Field  Medical 
Surveillance  System  (FMSS)  as  well  as  Disease  or  Non-Battle  Injury  (DNBI)  data. 
Artificial  or  pre-recorded  casualty  and  resource  data  can  be  injected  into  the  system  via 
the  Historical  Database  and  Playback  functions  of  the  tool.  This  enables  the 
NavMedWatch  tool  to  provide  a  significant  level  of  support  for  training  exercises  and 
after  action  reviews. 

2.0  Research  Performed 

The  research  goals  for  the  Phase  I  Option  period  (February  23,  2000  to  May  23,  2000) 
were  to  investigate  candidate  data  sources,  to  investigate  alternate  visualization 
techniques,  to  continue  work  in  the  Application  Analysis  area,  and  to  investigate  the  use 
of  Intelligent  Agent  and  Predictive  Simulation  technologies. 

2.1  Data  Source  Research 

After  conferring  with  one  of  the  Technical  Advisors  for  this  SBIR  contract  (Dr.  Bill 
Pugh,  NHRC),  the  decision  was  made  to  investigate  the  TMIP  program  as  a  possible 
NavMedWatch  data  source.  TMIP’s  goal  is  to  provide  informational  databases  and 
integration  centers  that  are  accessible  to  the  warfighter  anywhere,  anytime,  in  support  of 
any  mission.1  The  TMIP  data  investigation  involved  1)  determining  the  TMIP  database 
schema  and  external  interface  and  2)  determining  the  data  available  with  the  TMIP  Block 
1  delivery  versus  the  data  proposed  to  be  displayed  by  the  NavMedWatch  tool. 

Research  indicated  that  TMIP  is  divided  into  three  subsystems,  each  with  its  own 
database.  The  first  subsystem  is  known  as  the  Medical  Services  Delivery  System 
(MSDS)  located  at  each  individual  MTF.  The  database  associated  with  the  MSDS  is 
known  as  the  Local  Database  (LDB).  Users  can  access  the  LDB  through  the  Persistent 
Interface  (part  of  the  MSDS)  using  XML  (Extensible  Markup  Language).  XML 
provides  a  format  for  describing  structured  data  similar  to  the  way  HTML  provides  a 
format  for  visual  displays.  XML  is  a  text-based  format,  similar  to  HTML,  designed 
specifically  to  store  and  transmit  data.  The  second  subsystem  is  known  as  the 
Headquarters  Transactional  Processing  System  (HTPS)  located  at  the  JTF  Command  and 
Control  center.  The  database  associated  with  the  HTPS  is  referred  to  as  the  Interim 
Theater  Database  -  Online  Transaction  Processing  (ITDB-OLTP).  As  with  the  MSDS- 
LDB,  users  can  access  this  database  via  the  Persistent  Interface  using  XML.  The  ITDB- 
OLTP  database  stores  data  from  MSDS-LDB  to  provide  summary  MTF  status  to  JTF 
personnel.  The  third  subsystem  is  known  as  the  Headquarters  Analytical  Processing 
System  (HAPS)  also  located  at  the  JTF.  The  database  associated  with  the  HAPS  is 
referred  to  as  the  ITDB-Operational  Data  Store  (ITDB-ODS).  This  database  periodically 
receives  data  from  the  ITDB-OLTP  to  act  as  a  historical  database  for  the  theater.  Again, 
this  database  can  be  accessed  via  the  Persistent  Interface  using  XML. 


1  Theater  Medical  Information  Program  Operational  Requirements  Document,  pg.  1-1. 
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Figure  4  illustrates  an  example  configuration  of  the  interface  linking  NavMedWatch  and 
the  three  TMIP  subsystems. 


Figure  4.  NavMedWatch  and  TMIP  Interface 


The  three  TMIP  Block  1  database  schemas  were  studied  to  determine  if  the  proposed  data 
is  readily  available.  Figure  5  lists  the  NavMedWatch  data  to  be  displayed,  the 
appropriate  NavMedWatch  screen,  location  of  the  data  within  the  TMIP  databases,  the 
TMIP  Requirement  Number2,  and  an  alternate  data  source  (if  the  required  data  is  not 
currently  part  of  the  TMIP  databases). 
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Figure  5.  TMIP  Availability  of  NavMedWatch  Data 

Information  associated  with  situational  awareness  (such  as  bed  availability  and  patient 
status)  is  captured  in  the  TMIP  databases;  however,  the  staffing  information  (such  as 
personnel  availability  and  allocation)  is  not  available  with  the  TMIP  Block  1  delivery. 

An  alternate  source  for  this  information  will  need  to  be  identified.  The  alternate  source 
may  require  adding  a  manual  data  input  feature  to  NavMedWatch  allowing  this 
information  to  be  manually  entered  and  stored  in  a  local  database. 

Research  during  the  Option  period  also  indicated  data  shortfalls  in  the  areas  of  blood  and 
Class  VIII  supply.  Information  regarding  inventories  is  required  to  support  the  Predictive 
Simulation  function.  This  information  is  not  currently  stored  in  the  TMIP  databases.  The 
TMIP  functional  requirements  for  this  area  are  satisfied  by  using  external  components 
(DBSS  for  blood  supply  inventories  and  DMLSS  for  Class  VIII  supply  inventories). 

These  components  do  not  currently  provide  the  external  interfaces  needed  to  link 
NavMedWatch  to  their  data  stores. 

The  Identified  Bottlenecks  and  Time  to  Shortfall  data  elements  (part  of  the  Sensitivity 
Analysis  screens)  are  generated  using  CasFlow.  Under  U.  S.  Navy  SBIR  funding, 
ScenPro,  Inc.  has  developed  a  Casualty  Flow  simulation  tool  (CasFlow)  that  can  simulate 
the  movement  of  casualties  through  an  MTF  and  record  the  consumption  of  associated 
resources  over  time  (space,  staff,  equipment,  supplies,  and  transportation).  During  Phase 
II  of  this  effort,  CasFlow  will  be  incorporated  into  the  NavMedWatch  architecture  to 
provide  predictions  of  resource  needs. 
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2.2  Visualization  Research 

As  part  of  the  Option  period  tasking,  candidate  display  techniques  for  NavMedWatch 
were  analyzed  and  recorded.  Based  on  knowledge  acquisition  and  prototype  evaluation 
funded  under  the  Defense  Advanced  Research  Projects  Agency  (DARPA)  Biological 
Warfare  Defense  (BWD)  Program,  the  Viewport  tool  was  analyzed  in  depth.  ViewPort  is 
an  interactve  tool,  developed  by  ScenPro,  to  support  Commanders,  Planners,  and 
Emergency  Responders  with  enhanced  situational  awareness  and  visualization  capability 
during  critical  incidents  over  time.  ViewPort  provides  a  visual  representation  of  a 
defined  area  of  interest  using  underlying  electronic  maps  and  Computer-aided  drawing 
(CAD)  files  annotated  with  icons.  The  icons  can  be  easily  customized  to  represent 
personnel,  resources,  hazards,  alarms,  etc.  Figure  6  represents  an  example  Viewport 
screen  with  custom  icons  to  the  left  of  the  map  object. 


Figure  6.0  Example  ViewPort  Display 

The  ability  to  provide  an  intuitive,  custom  display  of  critical  medical  data  will  be 
incorporated  into  the  NavMedWatch  Phase  II  workplan.  Specific  areas  of  interest 
pertaining  to  NavMedWatch  include:  1)  the  use  of  custom,  domain- specific  icons,  2) 
application  of  drag  and  drop  functionality,  and  3)  the  use  of  an  underlying  map  display. 
Each  NavMedWatch  screen  could  be  represented  with  a  unique  icon  so  that  the  user  at 
the  primary  NavMedWatch  site  could  drag  and  drop  areas  of  interest  onto  the  main 
display  -  thus  allowing  the  user  to  in  effect  create  a  custom  view  of  the  selected  medical 
system.  With  the  use  of  the  underlying  map,  MTF  icons  can  be  placed  at  the  appropriate 
geographical  locations  creating  a  map  of  the  Theater  of  Operation.  This  map  can  be  used 
to  show  evacuation  routes,  evacuation  status,  modes  of  transportation,  etc.  At  the  JTF 
level,  a  user  could  double  click  on  individual  MTF  icons  to  bring  up  detailed 
characteristics  of  individual  facilities. 
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2.3  Application  Analysis  Research 

Additional  research  was  conducted  into  the  application  of  the  Scenario-based 
Engineering  Process  (SEP)  to  support  this  SBIR  project.  SEP  consists  of  three 
engineering  steps:  1)  Domain  Analysis,  2)  Application  Analysis,  and  3)  System 
Implementation.  The  Application  Analysis  step  includes  scenario  generation  and 
analysis,  functional  model  development,  object  oriented  analysis  and  design,  and 
performance  analysis.  During  the  System  Implementation  step,  ScenPro  will  implement 
the  new  system  while  providing  regular  feedback  to  shareholders. 

Much  of  the  work  performed  in  the  Phase  I  effort  (May  1,  1999  -  October  31,  1999)  was 
focused  on  the  Domain  Analysis  area  as  illustrated  in  Figure  7. 


Figure  7.  Domain  Model  Generation 

During  the  Phase  I  Option  period,  research  was  performed  in  the  Application  Analysis 
area.  Figure  8  illustrates  the  tasks  involved  with  Object  Oriented  Analysis  and  Design 
during  the  Application  Analysis  phase  of  SEP: 
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Figure  8.  Object  Oriented  Analysis  and  Design 

The  “Select  Objects”  and  “Determine  Attributes”  tasks  included  identifying  and 
describing  the  different  components  ofNavMedWatch  as  described  in  the  Section  1.1 
NavMedWatch  Components.  Figure  3  shows  the  key  components  of  the  tool. 

Specifically,  we  worked  with  the  Data  Interface,  System  Controller,  and  the  User 
Interface/Monitor.  Example  attributes  identified  for  the  User  Interface/Monitor  are 
export  path,  refresh  rates,  screen  layout  parameters,  color  guidelines,  hyper-link 
navigation,  and  user  profiles. 

An  on-going  task  of  Applications  Analysis  is  to  create  simulations  and/or  models.  This 
work  included:  1)  expanding  the  TMCS-type  interface  prototype  developed  during  Phase 
I  to  include  an  xml-type  interface  needed  to  retrieve  data  from  the  TMIP  databases;  and 
2)  developing  a  prototype  using  Visio  and  VBA.  The  prototypes  are  discussed  in  greater 
detail  in  Section  3.0  Prototype  Development. 


2.4  Predictive  Simulation  Research 

NavMedWatch  will  include  CasFlow,  a  discrete  event  simulation  previously  developed 
by  ScenPro,  Inc.  The  CasFlow  simulation  has  a  variety  of  uses,  but  the  original  one  was 
to  evaluate  the  appropriateness  of  a  medical  treatment  facility  (MTF)  and  its  resources  for 
a  particular  set  of  casualty  streams. 

To  operate  CasFlow  in  this  mode  there  are  three  sets  of  data  that  are  brought  together  and 
fed  into  the  discrete  event  simulator;  first,  an  MTF  is  designed,  including  its  layout,  staff, 
equipment,  and  supplies.  Second,  one  or  more  casualty  streams  are  generated  (either  by 
hand  or  using  casualty  rate  data  and  a  stochastic  model)  and  fed  into  the  simulator.  And 
third,  a  set  of  Task-Time-Treater  (TTT)  files  representing  the  treatment  protocol  for  each 
injury  called  out  in  the  casualty  streams. 

The  CasFlow  simulation  works  by  taking  each  casualty  and  moving  them  through  the 
MTF  in  accordance  with  the  steps  indicated  in  the  TTT.  Each  entry  in  the  TTT  file 
describes  a  task,  the  staff,  equipment,  and  supplies  required  to  perform  the  task,  the 
location  the  task  should  be  performed,  and  the  time  the  task  takes.  Whenever  a  particular 
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task  in  the  treatment  protocol  is  completed  the  simulation  finds  the  next  task  in  the  TTT 
and  the  casualty  is  moved  to  the  appropriate  location  in  the  MTF  and  staff  and  equipment 
are  applied  to  the  task.  During  the  task  various  supplies  are  consumed.  If  either  the  room, 
staff,  or  equipment  is  unavailable,  the  casualty  must  wait  or  be  evacuated  out.  The 
casualty  continues  to  use  the  room,  staff,  and  equipment  for  the  indicated  time. 

As  the  casualties  move  through  the  MTF  their  triage  category  is  used  to  allocate  the 
scarce  resources.  Each  casualty  is  "competing"  with  other  casualties  on  a  "highest  triage 
category  first"  basis. 

During  the  simulation,  data  files  are  created  indicating  what  transpired  in  each  room  and 
to  each  casualty.  When  the  simulation  is  complete,  these  data  files  can  be  analyzed  to 
determine  how  much  of  various  resources  are  required  to  properly  treat  all  the  casualties. 
By  comparing  these  requirements  with  the  MTF's  on-hand  resources,  shortfalls  can  be 
identified. 

The  CasFlow  simulation  engine  will  be  integrated  into  NavMedWatch  and  used  to  predict 
resource  usage  and  shortfalls.  The  basic  operation  of  this  component  of  NavMedWatch 
will  be  to  periodically  pre-load  the  CasFlow  engine  with  information  about  the  current 
casualties  -  including  patient  condition,  original  admit  time,  and  current  location. 
Configuration  details  about  the  medical  treatment  facilities  are  also  provided  to  CasFlow. 

Using  the  Task-Time-Treater  database,  CasFlow  will  then  simulate  the  treatment 
protocols  for  these  patients,  recording  resource  use  and  consumption.  The  simulation  will 
look  several  weeks  into  the  future  as  the  current  casualties  are  treated  and  evacuated  out 
of  the  theater. 

The  resources  required  by  the  casualties  will  be  compared  to  those  available  within  the 
MTFs.  Users  will  be  notified  about  any  shortfalls.  The  user  will  be  able  to  query  the 
system  to  understand  why  the  shortfall  is  expected  to  occur.  The  user  can  also  pursue 
solutions  to  alleviate  the  shortfall  using  the  Intelligent  Agent  component. 

Users  will  be  able  to  enter  proposed  solutions  to  the  resource  shortfalls  and  rerun  the 
simulation.  This  will  help  the  users  to  determine  if  their  solutions  will  minimize  the 
problem. 

2.5  Intelligent  Agent  Research 

The  job  of  the  Intelligent  Agent  is  to  offer  recommendations  about  how  to  reconcile 
predicted  resource  shortfalls.  The  function  is  invoked  by  the  user  in  the  direct  response 
to  a  shortfall  predicted  by  the  Predictive  Simulation  function. 

Based  on  research  performed  during  the  Option  period.  Intelligent  Agent  technology 
could  be  applied  by  accessing  information  associated  with  individual  MTFs,  outlined 
shortfalls,  and  end-user  characteristics.  For  example,  Intelligent  Agents  could  be  used  to 
select  among  pre-defined  “Help”  files  to  aid  the  user.  These  “Help”  files  will  be  based 
on  perceived  need,  level  of  education,  etc.  Additionally,  information  will  consist  of 
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optional  courses  of  action  that  can  be  taken  to  alleviate  shortfalls  and  provide  a  set  of 
associated  recommendations.  The  recommendations  provided  by  the  agents  may  include 
checklists,  contact  information,  expected  outcomes,  possible  side  effects,  and  help  with 
report  writing.  In  addition  to  MTF  and  user  data,  characteristics  that  might  be  used  to 
choose  between  different  recommendations  include:  DEFCON,  Op  Tempo,  Pers  Tempo, 
and  geographic  location. 

In  order  for  the  Intelligent  Agents  to  be  effective,  recommendations,  key  decision  points, 
constraints,  and  rules  must  be  gathered  from  subject  matter  experts.  After  various 
recommendations  are  identified  and  documented,  a  representative  set  of  experts  will 
characterize  them  according  to  priority,  applicability,  and  probability  that  the  action  will 
be  taken.  These  activities  will  take  place  during  the  knowledge  acquisition  activities 
outlined  in  the  Phase  II  work  plan. 

3.0  Prototype  Development 

During  the  Phase  I  portion  of  this  project,  a  prototype  tool  was  created  to  simulate  the 
interface  between  NavMedWatch  and  TMCS.  This  prototype  involved  writing  an  Active 
Server  Page  (ASP)  using  Visual  Basic  and  HTML,  to  open  a  Microsoft  Access  database, 
query  the  database,  and  then  write  the  requested  data  to  a  web  page.  In  this  case,  the 
user  is  viewing  the  NavMedWatch  displays  with  an  Internet  Explorer  browser,  and  then 
requesting  input  data  (such  as  TMCS)  across  the  network  from  a  Microsoft  Access 
database.  The  NavMedWatch  displays  were  built  using  HTML. 

In  the  Phase  I  Option  time  period,  the  prototype  was  modified  in  order  to  1)  experiment 
with  Visio™  as  the  mechanism  for  building  the  displays  and  2)  to  simulate  an  interface  to 
a  TMIP  database  using  XML.  The  system  configuration  for  the  prototype  is  illustrated  in 
Figure  9.  Note  that  the  primary  NavMedWatch  has  Visio  installed  and  uses  it  to  create 
the  customized  screens.  The  primary  watchboard  then  exports  the  different  screens  as 
HTML  pages  to  the  appropriate  directory  (in  this  case  c:/Inetpub/wwwroot).  New 
screens  are  exported,  as  HTML  pages,  when  the  Main  MTF  display  is  selected.  The 
remote  NavMedWatch  user  views  the  various  screens  via  an  Internet  browser.  The 
remote  user  is  a  passive  one  in  that  the  user  does  not  have  the  drag  and  drop  capability 
that  the  primary  user  has  with  Visio.  However,  the  remote  user  still  has  the  double-click 
functionality. 
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Figure  9.  Phase  I  Option  Prototype  Configuration 

The  extensible  Markup  Language  (XML),  used  for  interfacing  to  the  TMIP  database, 
provides  an  application-independent  format  for  storing  and  defining  data  by  providing  a 
common  format  for  requesting  and  transferring  data  using  HTTP.  In  addition, 
technologies  for  defining,  querying,  and  rendering  XML  documents  are  included.  The 
NavMedWatch  prototype  demonstrates  the  use  of  XML  at  the  client  side  to  request  data 
stored  in  XML  using  Microsoft’s  Rowset  schema.  The  NavMedWatch  client  reads  and 
parses  XML  documents  defined  using  the  Rowset  schema  and  creates  recordsets  that 
contain  the  requested  data.  A  utility  function  was  built  to  simulate  the  creation  of  the 
XML  documents  at  the  server  side.  This  utility  creates  XML  documents  from  queries 
performed  on  the  NavMedWatch  example  database  used  in  the  Phase  I  prototype. 

4.0  Plans  for  Phase  II 

4.1  Main  Effort 

Basic  Effort  -  NttvMedWsEcfi;  Bevdopmoat 

The  basic  effort  in  Phase  II  will  be  the  continued  development  of  a  Medical  Data  Fusion 
Watchboard.  This  work  will  build  on  the  prototype  tool  that  was  completed  during  the 
Phase  I  and  Phase  I  Option  effort.  The  process  of  User-oriented  Domain  Analysis,  Rapid 
Prototyping,  and  Object  Oriented  Software  Development  techniques  will  continue  during 
Phase  II  development.  Additionally,  training  applications  for  the  tool  will  be  researched 
and  applied  where  appropriate. 

In  the  Domain  Analysis  portion  of  the  effort,  an  exemplar  Scenario-of-Use  will  be 
developed.  Scenarios  are  selected  to  provide  a  representative  sample  of  training, 
demonstrating,  and  testing  examples.  They  identify  the  details  of  the  incident,  casualties, 
location,  events,  interactions,  individual  roles,  and  outcomes  at  a  high  level.  ScenPro  has 
created  a  comprehensive  set  of  CONUS  and  OCONUS  scenarios  developed  under 
DARPA  and  Navy  funding.  The  baseline  scenario  will  be  selected  from  those  already 
available  at  ScenPro,  or  developed  specifically  for  this  effort  if  needed.  During  Domain 
Analysis,  user  comments  are  solicited  to  optimize  the  scenario. 


Primary  NavMedWatch 
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Interactions  with  targeted  users  will  continue  and  prototypes  will  be  evaluated  and 
refined  based  on  user  input.  The  task  analysis  documents  produced  as  a  result  of  these 
sessions  will  be  key  drivers  in  the  development  of  the  NavMedWatch  tool. 

Potential  data  sources  will  continue  to  be  researched  and  evaluated.  Current  plans  will 
take  advantage  of  the  network-based  TMCS  system  as  well  as  available  TMIP  data. 
Various  devices  currently  being  evaluated  for  use  by  the  Navy  will  also  be  examined  - 
such  as  Status  Monitors,  Patient  Trackers,  and  Personal  Identification  Cards.  The  data 
sources  selected  will  be  analyzed  by  users  and  the  Data  Fusion  Guidelines  developed  in 
Phase  I  will  be  applied  as  appropriate.  A  common  database  schema  capable  of  storing 
each  datum  will  be  developed  and  populated  with  example  data,  then  with  data  from  the 
baseline  scenario. 


Once  the  data  are  defined  and  the  interfaces  have  been  prototyped  and  approved,  the 
system  will  be  implemented.  As  mentioned  above,  an  object-oriented  software 
development  methodology  will  be  followed.  As  optional  components  are  completed, 
integration  testing  will  be  performed  and  reported. 


Idditk’ii:  of  Prediictr/e  Simtalatioffi  FuiaetitonaMcy 


The  first  Option  proposed  for  this  effort  is  the  addition  of  Predictive  Simulation 
capability.  This  feature  will  provide  users  with  the  ability  to  predict  casualty  movement 
and  resource  consumption  at  the  MTF  and/or  the  JTF  levels.  Based  on  the  results  of  the 
simulation,  potential  resource  shortfalls  and  system  bottlenecks  will  be  identified  and  can 
be  resolved  accordingly. 


The  second  Option  being  proposed  for  this  effort  is  the  addition  of  an  Epidemiology 
function.  This  feature  will  capitalize  on  current  research  being  conducted  at  the  Naval 
Health  Research  Center  and  will  provide  users  with  alerts  of  potential  disease  outbreaks 
and  the  associated  resource  considerations.  Initial  efforts  will  focus  on  locating  and 
adopting  the  most  appropriate  epidemiological  model  based  on  available  data  stores. 


The  third  Option  being  proposed  for  this  effort  is  the  addition  of  Intelligent  Agent 
functionality.  This  feature  will  provide  users  with  a  group  of  intelligent  interviewing 
agents  to  assist  in  resolving  resource  shortfalls  and  system  bottlenecks.  This  will  have  an 
immediate  application  in  Military  Medical  Training.  (Phase  II  Option  1  must  be  included 
with  this  feature.) 


4.2  Bridge  Option 

Develop: /Adbpt  Migrcttest  Strategies 

The  proposal  for  optional  bridge  funding  will  focus  on  the  successful  development  and 
adoption  of  a  migration  strategy  for  the  NavMedWatch  Tool  during  Phase  III 
development. 
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5.0  Conclusion 

The  Real-Time/Predictive  Medical  Data  Fusion  Watchboard  described  in  this  report  will 
significantly  enhance  the  care  provided  by  the  current  Navy  medical  system. 
NavMedWatch  provides  medically  relevant  data  in  a  user-friendly,  streamlined  format 
that  allows  for  rapid  assessment  of  the  readiness  of  individual  MTFs  as  well  as  grouped 
together  within  a  theater  of  operation. 

The  features  provided  by  NavMedWatch  will  add  a  high  degree  of  intelligence  to  the 
present  medical  care  system  -  thus  making  NavMedWatch  much  more  than  just  a  status 
watchboard.  The  proposed  NavMedWatch  tool  has  the  capability  of  becoming  the 
“standard”  for  rapidly  visualizing  and  managing  U.  S.  Navy  medical  operations. 


